I’ve spent a bit of the bank holiday weekend by probably violating the warranty of a new 15” Macbook Pro (MBP) from work. I also was at the Debian bbq 2007 in Cambridge and met some friendly faces. :)

• I halved the HD to make way for Debian with Bootcamp and rEFIt. (I wonder how easy it is resize things again if needs be. Bootcamp does not seem to want to run again…)
• Unfortunately Debian’s grub isn’t patched for gpt (thanks cjwatson for the tip), so the install failed…
• The install CD got stuck inside and I discovered from mjg59 that holding down the mouse button whilst turning on the MBP ejects the CD. Phew…
• I’ve since installed Ubuntu Feisty, though since the X was failing to start with the nVidia video device, I decided to upgrade to gutsy. It works. :)
• Unfortunately a lot of other things do not work (without some tweaking), like sound, wifi and flash so…
• I’m now booting into the Ubuntu partition from MacOSX via VMware’s Fusion product. Niiice.
• I did try Debian lenny inside Fusion, but it doesn’t seem to do fullscreen at 1440×900. However, Ubuntu does. I guess the VMware guys tweak things.

More MBP & X40 porn So now I can boot into MacOSX and run Ubuntu or boot straight into Ubuntu from rEFIt. There are a couple of problems.

• I need to sudo dpkg-reconfigure xserver-xorg between vmware and nvidia drivers when I boot between
• Nevermind the right click, how the hell do I do a middle click for a paste?? (Fixed)
• The keyboard on the MBP does suck. For example if I click the bottom right edge of the key ‘t’, no ‘t’ shows up. It feels wrong, though I guess I have to get used to it.
• The MBP runs hotter and louder than the X40. Of course the MBP is heavier too, hence the MBP isn’t what I class a ‘laptop’
• Effectively Ubuntu under VMware will be much slower than X40 with Debian lenny. So, this hardly feels like an upgrade. ;)
• I really don’t like the windowing MacOSX interface. I need to figure out how to compile (Xlib.h not there) and run a “tabbed WM” dwm on the MBP natively.
• A lot of the Apple software just sucks!

There are some things I quite like about the MBP compared to the X40:

• Bigger screen 1024×768 -> 1440×900
• Wifi that remembers the connection details
• Faster bootups
• I actually like the glossy screen (when there are no reflections on it)

Currently I remain not totally convinced about the Apple MBP. I’ll keep my Debian X40 my personal machine and the MBP for work. Now I can compile Webkit on Apple OSX (Debian can too) and see what’s happening in Ubuntu.

There are a gazillion HOWTOs out there for flashing a BIOS image without having to resort to ugly "boot DOS from floppy" or "run Windows *.exe file from BIOS vendor" and other ugly stuff. Unfortunately, the proposed solutions are equally ugly (e.g. creating custom CD-ROMs which contain the "floppy" with DOS/Windows flash tools). Folks, this is so much simpler than you think: The flashrom tool (GPL'd, written for LinuxBIOS purposes, but works perfectly fine with proprietary BIOSes, too) will easily do what you want, on a running Linux system. No floppy crap, no CD-ROM crap, no DOS/Windows crap, no rebooting crap. Install it:

$ apt-get install flashrom

Detect whether flashrom knows about your chipset/mainboard/BIOS chip:

$ flashrom

Read the BIOS image into a file:

$ flashrom -r backup.bin

Write a BIOS image (proprietary or LinuxBIOS) on the ROM chip:

$ flashrom -wv newbios.bin

WARNING: This will overwrite your current BIOS! Make sure you know what you're doing! For the Debian-challenged, flashrom is available in source form too, of course:

$ svn co svn://linuxbios.org/repos/trunk/util/flashrom
$ cd flashrom
$ make

The list of supported chipsets, mainboards, and ROM chips is limited of course, but it's constantly expanding. Contact us on the LinuxBIOS mailing list if you want other hardware supported (or even better: if you have patches!). In many cases adding support for new hardware is pretty easy...

With the Post-etch frenzy, I installed Debian 4.0 stable as soon as I could. I used the same system used a few months ago for the google Summer of Code. Under the same conditions, the system required 32 seconds until KDE started. Compared with the previous stable releases:

• Woody - 32 seconds
• Sarge - 44 seconds
• Etch - 32 seconds

Nevertheless, Etch has significantly more process started at boot time and the CPU usage is more intensive --with still some room for improvement --. Follow this link for the bootcharts and more detailed information.

As I starting point, using dash instead of bash, the boot time is reduced to 30 seconds and it could be further improved but there is some "hald" process (maybe part of dbus) that doesn't seem to want to run in parallel. See bootcharts. Any ideas?

So I’ve got my shiny new laptop which should complement my 5 years old PowerBook G4 500 MHz and had a bit of fun installing Debian AMD64 on it. I did it the hard way, not using debian-installer as it was a given for me that both the kernel and debian-installer itself were unable to deal with the machine. Installation method:

• debootstrap an amd64 system and an i386 system on a FireWire disk
• build a suitable x86_64 kernel for the MacBook Pro, handpicking patches from mactel-linux
• reinstall a fresh and stripped down Mac OS X system on a smaller partition
• boot on the mactel-linux live CD
• partition using parted
• sync GPT and MBR with gptsync
• mkfs, mkswap
• transfer the amd64 system using xfsdump/xfsrestore
• chroot into the i386 system, edit lilo.conf, run lilo
• reboot, hold down the option key, choose the infamous “Windows” icon
• ENJOY

Note that you do not need to install BootCamp on Mac OS X. On the Core2 Duo machines, the firmware already includes the SMBIOS stuff, so you’d only install a useless Mac OS X GUI which you can’t use because you’ve repartitioned before running BootCamp Assistant :-) Current status: most of what should work with Linux sort of works (that is, to say, everything but the WiFi). Things that do not work:

• external VGA monitor: a DVI-D monitor works fine, looks like fglrx does not enable the DVI-I output on the DVI connector (it even reads the EDID data from the VGA monitor). If you know someone at ATI, please point them to this post. My bug report to ATI has been discarded with this comment: “we do not supply drivers for laptops, it’s up to the manufacturer” (roughly). Yeah, right. Not buying ATI anymore if this doesn’t get fixed.
• WiFi: new Atheros5008 a/b/g/pre-n chip, unsupported by madwifi and future support is uncertain at best as of now. Happy. NOT. (madwifi ticket #1001)
• sound: sort of works with Linux 2.6.18, sound works on both headphones and speakers. Broken in 2.6.19. (ALSA issue #2198)
• no keyboard in LILO: strange, but the keyboard doesn’t work at boot time in LILO when run through rEFIt, though it does sometime work when run directly from the Apple chooser. lilo -R to the rescue, but this is painful. Maybe GRUB would work better.
• applesmc: has issues, the SMC times out frequently. Works nonetheless, and it does not happen when first booted into OS X. Probably an initialisation issue.
• trackpad: doesn’t work as good as in Mac OS X, some synaptics config tuning should fix that
• battery life sucks: power consumption is a steady 26 W for a 55 Wh battery, even with both cores running at 1 GHz instead of 2.33 GHz. Power consumption doesn’t vary depending on the CPU frequency. Bug ?

Everything else works, and works fine. Wrote a small daemon to handle the special keys for LCD backlight, sound, keyboard backlight and CD ejection. Still needs a bit of polishing, after what I’ll release and package it. rEFIt isn’t available in Debian AMD64 yet, so gptsync isn’t available and must be run from an i386 system for the time being (plus gptsync is buggy on 64bit architectures). Patches ready, waiting for GNU-EFI on amd64 (#383801). Suspend to RAM and suspend to disk both work, use s2ram -f -p -m until the machine makes it into the built-in whitelist. The machine is pretty nice, though I’d appreciate it if the fans weren’t running at 5500 rpm when I have the laptop on my laps. Might be related to both the applesmc and power consumption issues. WiFi remains the biggest issue, battery life comes second ex-aequo with DVI-I output and sound is third. I’m quite unhappy with having to taint my kernel by using the fglrx (and madwifi in the future) proprietary crap, and even more when it doesn’t work as good as it should. Maybe RMS was right about ATI.

It is funny to see that when I remove discover (/etc/rcS.d/S36discover) from the boot, a disk utilisation and cpu usage peak appear at the end of loading KDE. Would it be that discover is loaded by KDE if it wasn't loaded? Or a discover ghost :p. Well, the bootcharts for the two different cases are available here.

I've tried prelinking with the aim of making the boot faster. I've used the package of prelink from debian in unstable and we get no significant time improvement. Prelinking was added after readahead in a custom script run during the boot in /etc/rcS.d/S70prelink. What the script does is to prelink: kdeinit, Xorg, kwin, kdesktop, kicker, artsd, kaccess, ktip, klipper and korgac. The bootcharts are availabe here.

By removing useless init-scripts from the symbolic link pool (/etc/rc?.d) we got a further second improvement in the boot time. The two init-scripts removed were hotkey-setup and gdm. The former can be removed as I'm not using a laptop and the latter because I'm using KDE. The boot time was reduced from 46 to 45 seconds. See the new bootchart and compare with the reference bootchart.

I've been playing a bit with Ubuntu's readahead to get a better boot time on debian. At least they seem to get it. I've used strace to get the list of files for different init-scripts and generate the required /etc/readahead/boot file - containing the files to load to memory. The advantage of readahead over preload so far is that it does not affect the boot time when it is not active. I consider readahead inactive when the boot file is empty and preload when the preload script is removed from the symbolic link pools (/etc/rcX.d).

By using readahead shortly after the system starts to boot (near udev), the boot time is even increased by 2 seconds (e.g. S03readahead in /etc/rcS.d). On the other side, by using some of the files used by KDE during startup there is almost a one second improvement as may be seen in the bootchart. We use readahead in /etc/rcS.d position S42. The list of files and the bootcharts may be found here.

Besides, I've corrected the deliverable 5 including the fact that lintian incorporates now a check for lsb compliance based on our patch! The deliverable is available here

With the alioth sever down, it seems our project webpage is down as well. Anyway, we are currently on a 7 second improvement of the boot time by using reordering, dash as /bin/sh and hwclock in the background. The bootchart is available here while that of the original system here. No time was won using preload 0.4 with varied configuration combinations. Curious to see that the time is 2 seconds more even without preload in the symbolic link farm (/etc/rcX.d) when preload is installed.

The new deliverables 3 and 5 were published. In the third deliverable we mention the effect of most hotspots, the procedure used for testing them and their bootcharts. Besides, it contains a group of combinations done with the hotspots and their effect. Deliverable 5 simply consists of the LSB guide for maintainers and the lintian patch to check LSB compliance. Both issues were published some weeks ago and this deliverable was just published to comply with the original deliverable list. Still two deliverables are missing: Deliverable 4: a proposal to change the boot system in debian according to the results from Deliverable 3 and further research, and Deliverable 6: the final report of the project. They are available in the deliverables webpage

...do a lot of different things while your new Debian Desktop is booting.<br /><br />Well, it's clear that some people in the project are thinking how we can speed up the boot times (no unfortunately i wasn't at debconf). I would like to invite you to split your ideas in two groups: a) Good For Etch; b) Dreams. :P My point here is that with what we've today, without break too much stuff for sure, applying some work where it's necessary we will have something good in December.<br /><br />Btw, i ran bootchart on three scenarios, using the latest weekly built image of testing, installing the desktop task, see my results:<br /><a href="http://www.flickr.com/photo_zoom.gne?id=151973355&size=o">Boot without changes (gdm left out)</a> - 2 m 29 s<br /><a href="http://www.flickr.com/photo_zoom.gne?id=151973357&amp;size=o">Adding "CONCURRENCY=shell" in /etc/default/rcS (gdm left out)</a> - 1 m 46 s<br /><a href="http://www.flickr.com/photo_zoom.gne?id=151973356&amp;size=o">Installing insserv and following the instructions in its README</a> - *1 m 29 s*<br /><br />I would like to hear what's the status of this "concurrency" stuff in /etc/default/rcS (is startpar default in sid now?) and if it breaks something. The other point is that we could push insserv tests forward, please read the documentation and do it yourself preparing your own bootchart results for comparison.<br /><br />The next step would add LSB headers in our init scripts, that will take more time because it involves a lot of packages. I think if we can guarantee that insserv and its dependency tree is ok, then we have the needed headers but they're not in the packages. We could release Etch this way, and add this workload to the individual maintainers of packages with init scripts during Etch+1 release cycle.

Some time ago I posted having obtained a 2 second time decrease in the boot time using insserv reordering. In that occasion, I had already deleted some repeated init scripts from the insserv modified /etc/rc2.d directory. Recently, I had problems using insserv as I thought the major change was just to change the order of some of the init-scripts (stop-bootlogd, sysklogd, klogd). Now, from a system starting in 53 seconds I got a 2 second improvement by using the same script order used some time ago. Besides, I thought I shouldn't bother to delete the repeated init-scripts as /sbin/init is supposed to ignore them. Nevertheless, by removing the remaining repeated scripts I got a further 2 second time improvement, i.e., a 4 seconds improvement! The bootcharts and init order are available at the project webpage.

Currently recovering from a disk failure with lots of data lost (i'll backup more often now), I'm trying to tackle with the inconsistencies sketched in the previous blog: preload and parallel booting hotspots don't perform as before. I guess the discrepancies came from playing too much with the boot process.
The new system has originally a boot time of 52 seconds and the installation of preload 0.4 on a freshly installed system gave 1 second longer boot time during the first reboot and came back to the original time after 4 reboots and goes back to 53 seconds afterwards.
The bootchart is available on the bootcharts section of the project webpage for two preload configurations.

Besides, unverbose booting was tested. Well, simply verbose was changed to "VERBOSE=no" and "VERBOSE=quiet" just making the system slower! What could this be? Manual tweaking may be probably needed. The bootcharts for the different cases are available on the bootcharts section of the project webpage

Finally, a laptop testing system was prepared for comparison. It has also a fresh debian sid installation on an external USB hard drive. The results using the laptop test bed were similar for unverbose booting although the boot time seem to be unconsistent! Around 2 second changes without networking and higher with networking. I _guess_ a possible reason is by using an usb hard drive.

I've tried preload 0.2 and 0.4 to compare its effects. Unfortunately my results don't hold with the results obtained some blogs ago: preload 0.2 reduced the boot time by 2 seconds. In this occasion, time was even lost (making me remember my first tests). This may be due to some upgrades had been made to sid since.
First I tried preload 0.2 with default with 1 second lost and a modified configuration with no boot time change.
Then I tried preload 0.4 with default and modified configuration both with no time change.
The bootcharts and log file are availabe at the project webpage.
Yesterday I presented a table with hotspots combinates and unlike it was expected, preload may not be helping anymore (preload 0.4 was used).

One again I've tried the preload program from Behdad Esfahbod (a result from SoC2005) but this time positive results. The cause of the difference might have been an incorrect deinstallation of parallel booting (insserv/startpar). The boot time showed a 2 second time improvement. The preload.conf parameters mapprefix and exeprefix were set to empty such that all files would be accepted. The results were compared with mapprefix being set to the directories used by some of the init scripts (strace -f initscript), adjusting the quantum time of preload (cycle parameter) and changing the position of the initscript to start just after hwclockfirst.sh. The results were the same: a 2 second time improvent. See the bootcharts here.

A bug was found when doing parallel execution with startpar. The scripts seem to have been executing twice and it is being fixed by Petter Reinholdtsen. To compare the effect of the bug, the parallel execution boot time using startpar was compared with the one using "shell". The main difference between using CONCURRENCY=startpar and CONCURRENCY=shell in /etc/default/rcS is that the latter doesn't care about the order in which messages are printed to the screen.

The issue made me try things again and this time I didn't accept the default script reorder from insserv. Insserv seems to have the following reordering issues:

a)repeates scripts in /etc/rc2.d that were already started in /etc/rcS.d
b)doesn't reorder /etc/rcS.d
c)puts stop-bootlogd near the beginning in /etc/rc2.d and bootlogd while sysklogd and klogd are at the middle.
d)includes scripts present in /etc/init.d that were not previously executed at boot time.


Issues (a) and (c) were corrected and the boot time was 2 seconds faster than without insserv(See bootcharts).
While testing parallel execution, using CONCURRENCY=startpar, there was no improvement (the bug hasn't been fixed) and while testing with CONCURRENCY=shell there was a 4 second time improvement from the original system without insserv. (See bootcharts)

In one of this extremely weird sunny and warm days in Dublin, I've met my google SoC mentor Petter Reinholdtsen. We've discussed several issues of the project and here are the main points:

1. Some small issues in the LSB compliance list needed to be corrected. Some packages didn't showed their package. It was solved and now all the init-scripts have the package they belong to. See LSB-compliance list.

2. It was important to compare the results from two different ways to use dash instead of bash in the init-scripts. See discussion in debian-devel. The two approaches are:

a) make /bin/sh point to /bin/dash - using the procedure described in /usr/share/doc/bash/README.Debian.gz, we obtain a time reduction of 4 seconds.
b) change #!/bin/sh for #!/bin/dash in the init-scripts - using the substitution function of sed, the initscripts were changed to use dash. A reduction of 2 seconds was obtained.

The bootcharts are available here. The difference should be because some programs are still using bash as just the first line of the initscripts was changed.

The base distribution I'm using for Sid changed slightly by installing ssh. There was no boot time difference. The new base bootchart (same time 49 sec) is here.

Based on a discussion in initscripts-ng-devel between Petter Reinholdtsen and Erich Schubert, I decided to try ubuntu's readahead to see if we will get a better or worst boot time. After installing ubuntu's readahead 1.0.1-2 but noticed not time difference. No difference was obtained by changing the boot order (S39 to S19 in rcS.d) nor by adding files read at /etc/readahead/readahead. The bootchart is here

Also tried the newer readahead from ubuntu readahead 0.20050517.0220-0ubuntu3 but now with a loss of 1 second. This includes two scripts S01readahead and S39readahead-desktop in rcS.d and S99stop-readahead in rc2.d. The bootchart is here

Next I'll try to analyze the SUSE static preload.

Besides I filed an bug (377941) to initramfs-tool I had with installing Etch on my laptop with a usb harddisk. Tried adding sleep 5 to /usr/share/initramfs-tools/scripts/init-premount/udev, then dpkg-reconfigure linux-image-.... but still fails :(

Yesterday I started to prepare bug reports about missing LSB headers. Since then I reported:
-acpid script #376778
-atd script #376780
-bittorrent script #376944
-exim4 script #376953
-hotkey-setup script #376955
-inetd script #376956
-kdm script #376958
-lpr script #376960
-makedev script #376992
-nfs-common script #376976.
A summary of the bug reports with missing lsb headers can be found in here
Besides, we've raised the issue of some scripts missing dependencies in the bootclean init script and the missing Should-Start dependency of bootmisc.sh in the sysvinit-devel mailing list.

I started to try another hotspot: preload. Unfortunately, I noticed no change on the boot time after installing preload. Not even after changing its boot order from /etc/rc2.d/ to /etc/rcS.d/ after the dependencies were met: in the init script it claims to require $time, $remote_fs and $local_fs. I believe seeing it in ubuntu at just the beginning of /etc/rcS.d/. The bootcharts and test procedures can be seen here. This is an issue that has to be further investigated.

On the other side, the lsb check script was debugged a little bit more. A list with the compliance of the init scripts in sid is available here. The few LSB compliant scripts are on the top, the big incomplete majority in the middle and those without LSB headers at the bottom.